home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄3⁄90 / 1677-Failing in PoseModal-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.6 KB  |  56 lines  |  [TEXT/GEOL]
  1. Item    4911385                         1-Aug-90        15:12PDT
  2.  
  3. From:   PILLAR.CORP                     Pillar, Chris Ovard,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Failing in PoseModally
  8.  
  9. Dear MacAppers:
  10.     No one likes to face failure on a daily basis, but ... Lately we've been
  11. testing our program in low memory conditions, and were wondering if the failure
  12. handling in TDialogView.PoseModally is as robust as it should be.
  13.       PROCEDURE HdlPoseModally(error: OSErr; message: LONGINT);
  14.     BEGIN
  15.          IF error = noErr THEN
  16.             GOTO 1 { If no error then keep the dialog running }
  17.          ELSE
  18.             BEGIN
  19.             fDismissed := TRUE;    { Avoid validating selected edit text }
  20.             itsWindow.Close;   { If an error then close the dialog and exit
  21.                              via failure mechanism }
  22.             END;
  23.     END;
  24. This handler jumps back into PoseModally for the case of "error = noErr"
  25. (usually means that CanDismiss was False when called from Dismiss Dialog), but
  26. otherwise closes the window and passes the failure up to the next handler. I
  27. see two problems with this failure handler. The first is mostly my opinion on
  28. how the failure should be presented to the user. The second is how one can
  29. programmatically recover from this failure.
  30.  
  31.     First, as a user, when I get a failure in a modal dialog, I don't expect
  32. the dialog to be closed, rather I expect to get an alert and continue on in the
  33. same dialog. This could be accomplished by the following failure handler:
  34.       PROCEDURE RecoverPoseModally(error: OSErr; message: LongInt);
  35.      BEGIN
  36.          IF (error <> noErr) THEN
  37.             gApplication.ShowError(error, message);
  38.         GOTO 1;
  39.     END;
  40. I realize that the call to ShowError can fail, but if that could be magically
  41. avoided, what problems would be caused by using this handler instead of
  42. HdlPoseModally?
  43.  
  44.     Second, as a programmer, I don't know what state things will be in after a
  45. failure in PoseModally. If PoseModally fails in any of the method calls before
  46. the call to CatchFailures, the failure handler for the method that called
  47. PoseModally will need to free and/or close the window. If the failure is
  48. handled by PoseModally, the window has been closed (and freed if
  49. fFreeOnClosing.) This seems to be inconsistent (a bad quality for failure
  50. handlers). The above failure handler solves this problem also, because the
  51. calling method's handler is now ALWAYS responsible for cleaning things up.
  52.  
  53.     If anyone has a better solution or comments on the above I'd be interested
  54. in hearing from you soon. Thanks.
  55.  
  56.